https://http1mustdie.com #今天看了啥
tldr:
- http1 实现各异，难以区分消息的边界，易请求走私。
- proxy 与后端间应当使用 h2。
- 客户端与 proxy 间使用 h1 仍是安全的。
tldr:
- http1 实现各异，难以区分消息的边界，易请求走私。
- proxy 与后端间应当使用 h2。
- 客户端与 proxy 间使用 h1 仍是安全的。
🤔4
This media is not supported in your browser
VIEW IN TELEGRAM
有幸在生产中遇到了生日问题，最终导致数TB数据丢失。故事是这样的。
每个客户端会产生：
{hostname}_{年月日时分秒}_{纳秒的前三位}_{五位递增循环计数}.zst.open
这样的文件，每写满10多GB后重命名去掉 .open 后缀然后上传 S3。
如果客户端爆炸了，会有一个收尸的 rclone 进程把全部的 .open 也上传到 S3。
总之就这样跑了两个星期，产生了 50 多万个 .zst 与 .zst.open 文件，其中有 12 万是爆炸了的 zst.open 文件。（爆炸比例有点高，但是问题不大，主要是 graceful shutdown 坏掉了，于是每次触发新的 k8s 部署都会让所有客户端爆炸。灵）
于是今天要做的事情就是跑一下后处理，把 S3 里的这些 .open 文件，truncate 掉文件尾部的不完整垃圾数据后回传 S3。流程是：
1. 从 S3 下载 .zst.open
2. 本地 truncate .zst.open 并重命名为 .zst
3. 上传 .zst 到 S3
4. 删除 S3 中的 .zst.open
---
理论上，只要每个客户端的 hostname 是唯一的，就永远不会出现同名的 .zst 与 .zst.open。
只有一个例外：我的后处理程序完成了第3步但还未完成第4步时。
我考虑到了这点，于是加了个在步骤1下载 .zst.open 之前先检查一下 S3 里是否存在同名的 .zst 的机制。如果存在，说明上次运行后处理的时候卡在了步骤4，那就直接跳到步骤4重新执行。（幂等）
---
写完后处理的脚本，我丢到服务器上一跑。眨眼间刷了几百上千行 deleting .zst.open 的日志。我愣了十秒，“不对劲啊，我第一次跑，怎么会有同名文件呢”，赶紧 ctrl-c （已经晚了，删得只剩下十几个 .zst.open）。
---
一分钟后突然意识到我这是遇到了生日问题。因为每个客户端的 hostname 其实并不是唯一的！
之前可能是为了提高网络性能，同事把容器的网络从 bridge 改成了 host，导致 hostname 从原本随机生成的变成了跟随宿主机。
这次运行又比较猛，平均每个宿主机上起了三四个容器（客户端），每个客户端会在启动时几乎同时创建 64 个 .open 文件用于写入。
再加上我们取的纳秒的前三个数字而不是后三位数字，扩大了同一宿主机上不同客户端在一秒内启动时的碰撞概率。
最终导致不同客户端有极小概率创建出同名的文件而撞车。又因为跑了两个星期创建出了50万文件，极小概率撞车变成了必定有几百上千个撞车的生日问题。
---
还得幸亏我们的客户端的 graceful shutdown 很灵车，致使爆炸的 .open 文件很多，暴露出了这个问题。要是我们的 graceful shutdown 做得更完善一点，最终的结果会是 S3 没有这么多 .open 文件，撞车文件都会静默覆盖原本的同名文件，可能我们得要很久很久以后才能意识到这个问题。
每个客户端会产生：
{hostname}_{年月日时分秒}_{纳秒的前三位}_{五位递增循环计数}.zst.open
这样的文件，每写满10多GB后重命名去掉 .open 后缀然后上传 S3。
如果客户端爆炸了，会有一个收尸的 rclone 进程把全部的 .open 也上传到 S3。
总之就这样跑了两个星期，产生了 50 多万个 .zst 与 .zst.open 文件，其中有 12 万是爆炸了的 zst.open 文件。（爆炸比例有点高，但是问题不大，主要是 graceful shutdown 坏掉了，于是每次触发新的 k8s 部署都会让所有客户端爆炸。灵）
于是今天要做的事情就是跑一下后处理，把 S3 里的这些 .open 文件，truncate 掉文件尾部的不完整垃圾数据后回传 S3。流程是：
1. 从 S3 下载 .zst.open
2. 本地 truncate .zst.open 并重命名为 .zst
3. 上传 .zst 到 S3
4. 删除 S3 中的 .zst.open
---
理论上，只要每个客户端的 hostname 是唯一的，就永远不会出现同名的 .zst 与 .zst.open。
只有一个例外：我的后处理程序完成了第3步但还未完成第4步时。
我考虑到了这点，于是加了个在步骤1下载 .zst.open 之前先检查一下 S3 里是否存在同名的 .zst 的机制。如果存在，说明上次运行后处理的时候卡在了步骤4，那就直接跳到步骤4重新执行。（幂等）
---
写完后处理的脚本，我丢到服务器上一跑。眨眼间刷了几百上千行 deleting .zst.open 的日志。我愣了十秒，“不对劲啊，我第一次跑，怎么会有同名文件呢”，赶紧 ctrl-c （已经晚了，删得只剩下十几个 .zst.open）。
---
一分钟后突然意识到我这是遇到了生日问题。因为每个客户端的 hostname 其实并不是唯一的！
之前可能是为了提高网络性能，同事把容器的网络从 bridge 改成了 host，导致 hostname 从原本随机生成的变成了跟随宿主机。
这次运行又比较猛，平均每个宿主机上起了三四个容器（客户端），每个客户端会在启动时几乎同时创建 64 个 .open 文件用于写入。
再加上我们取的纳秒的前三个数字而不是后三位数字，扩大了同一宿主机上不同客户端在一秒内启动时的碰撞概率。
最终导致不同客户端有极小概率创建出同名的文件而撞车。又因为跑了两个星期创建出了50万文件，极小概率撞车变成了必定有几百上千个撞车的生日问题。
---
还得幸亏我们的客户端的 graceful shutdown 很灵车，致使爆炸的 .open 文件很多，暴露出了这个问题。要是我们的 graceful shutdown 做得更完善一点，最终的结果会是 S3 没有这么多 .open 文件，撞车文件都会静默覆盖原本的同名文件，可能我们得要很久很久以后才能意识到这个问题。
😱10😢1
https://blog.cosine.ren/post/git-worktrunk-guide
我也觉得 worktree 啰嗦了，试了下 worktrunk (https://worktrunk.dev/)，确实好用。
我也觉得 worktree 啰嗦了，试了下 worktrunk (https://worktrunk.dev/)，确实好用。
yzqzss|一座桥在打工 log
今天终于找到了根本原因：
GitHub
Fix connection leak by yzqzss · Pull Request #179 · internetarchive/gowarc
The underlying response.Body (connection) of the gzip responses were not closed, since they have been replaced by the gzip reader.
(Theoretically, this affects all responses with Content-Encoding: ...
(Theoretically, this affects all responses with Content-Encoding: ...
😁1
yzqzss|一座桥在打工 log
但幸好可以传入 ctx 来直接 cancel 整个请求/连接，所以这个问题也解决了。
然而并不是完全是这样。
golang 的 request.ctx 确实会被用于整个 roundtrip 生命周期。但在 ctx 传入 getConn() 并将要传入对应的 dialer 前，标准库会从 request.ctx 派生出一个 dialctx，这个 dailCtx 用 context.WithoutCancel() 屏蔽掉了 request.ctx 的 cancel 信号。
golang 的 request.ctx 确实会被用于整个 roundtrip 生命周期。但在 ctx 传入 getConn() 并将要传入对应的 dialer 前，标准库会从 request.ctx 派生出一个 dialctx，这个 dailCtx 用 context.WithoutCancel() 屏蔽掉了 request.ctx 的 cancel 信号。
GitHub
go/src/net/http/transport.go at 831c489f9cb9afa560ac3c5b79acc8ea5a62e414 · golang/go
The Go programming language. Contribute to golang/go development by creating an account on GitHub.
🤔2
Forwarded from 小金的 碎碎念&日常
【完全解析】青森灼柳p多次使用AI编曲的证据分析 // 新假弹王Oscar
从这个视频，学到了这个知识：
目前的Diffusion based模型生成的音乐，进行Mid/Side分离后，在side侧，16k+的能量会明显低。
于是快速搓了demo，拖进去flac/wav即可。
https://aimusicdetect.streamlit.app
主要还是从频谱图特征，有可能误伤的是，bgm用了有损，在此基础上翻唱，又用的是如ace这些AI音源，又没做特别的混响/其他处理，Mid/Side在16k+的比例也会有问题。
全都是vibe的代码，仅检查了Mid/Side能量计算没问题，其他的几项未检查。也无法保证查出，查出的也可能没用AI，仅供参考。
从这个视频，学到了这个知识：
目前的Diffusion based模型生成的音乐，进行Mid/Side分离后，在side侧，16k+的能量会明显低。
于是快速搓了demo，拖进去flac/wav即可。
https://aimusicdetect.streamlit.app
主要还是从频谱图特征，有可能误伤的是，bgm用了有损，在此基础上翻唱，又用的是如ace这些AI音源，又没做特别的混响/其他处理，Mid/Side在16k+的比例也会有问题。
全都是vibe的代码，仅检查了Mid/Side能量计算没问题，其他的几项未检查。也无法保证查出，查出的也可能没用AI，仅供参考。
🤔1